Factory automation system networks have historically been connected using direct point-to-point wiring or serial fieldbuses. In both of these types of networks, control signals are the only signals present on the wire. When factory automation networks used a serial fieldbus or even a point-to-point 4-20 mA (milliampere) bus, the network had little to no influence on the operation of the field device.
Ethernet is one standardized system network that has become widespread in factory automation. One key reason for switching to an Ethernet based network is that a factory can be made more intelligent by way of additional network applications and data management.
In Ethernet networks, control signals have to coexist with other network traffic. Thus there is much more activity going on over an Ethernet network than simply passing time sensitive data to and from the end field devices.
All of this activity on the network is a “necessary evil” and can dramatically influence the response of the field device. This activity can be so overwhelming for devices that time sensitive data stops being managed by the device.
Additional network traffic is generated during network configuration. Each field device must understand the network around it, so management traffic is constantly travelling around the network updating network topology information. When a field device anywhere in the factory is replaced, this will cause an increase in network management traffic as the devices reconfigure. Web servers inherent in many field devices provide a convenient means to configure, read status and perform updates and are the source of additional network application traffic.
Network traffic on an Ethernet bus comprises industrial Ethernet traffic plus traffic from standard Ethernet sources, network management protocols, diagnostic tools, and network applications. The industrial Ethernet traffic is analogous to the traffic out on a traditional field bus system and is time sensitive traffic commanded by a programmable logic controller (“PLC”) or digital control system (“DCS”) and contains cyclic updates for field device data parameters.
Any component of network traffic can cause temporary heavy network load conditions or a surge. Such a surge can be caused by any number of events in the system. One common event is an address resolution protocol (“ARP”) burst, or “ARP storm”. An ARP storm can be caused by simply plugging a maintenance personal computer (“PC”) into an otherwise stable network. In order to discover the devices on the network, such a PC will often send an identity broadcast request to the network. Every device will receive this broadcast but no device can respond until it updates its ARP table to contain the PC's Internet protocol (“IP”) address. So every device will simultaneously send an ARP request broadcast to learn the PC's IP address, causing the network traffic load to surge. Surges can also be caused by faulty equipment and by Denial of Service (“DoS”) attacks.
Standard Ethernet traffic is from other non-automation applications on the bus and in the end device. This can be data destined for a printer from a human machine interface (“HMI”) device on the network, or quality data destined for the front office. Typically, standard Ethernet traffic is minimized on the factory floor.
Network management and diagnostic traffic is required to keep the network infrastructure working properly. Simple Network Management Protocol (“SNMP”) is used to query and control elements on the network, e.g., switches, HMIs, sensors, actuators, PLCs, printers, etc. Link Layer Discovery Protocol (“LLDP”) provides information about the layout of a network and can be used in re-configuring a system, as is the case when a faulty device is replaced. ARP is used by many higher-level applications to query for addressing information.
In an improperly organized network, an ARP storm can result from broadcast messages being endlessly propagated through the network, demanding a high percentage of network bandwidth. This situation can happen during commissioning or maintenance simply by inadvertently creating a loop by connecting two ports of an unmanaged switch or misconfiguring a managed switch. Every field device on the network, e.g., sensor, actuator, PLC, HMI, etc. must handle this additional traffic.
Network Applications traffic is generated by “layer 7” programs and protocols that are used as utilities by other programs. Many field devices have a web server utilizing Hypertext Transfer Protocol (“HTTP”) to configure the device. Transferring files to and from a PLC or DCS typically uses File Transfer Protocol (“FTP”). Keeping time on the network typically uses Simple Network Time Protocol (“SNTP”) or Institute of Electrical and Electronics Engineers standard IEEE 1588. Within industrial Ethernet protocols themselves, there is much traffic that is necessary for establishment and maintenance of the connections between PLCs and devices. These include Remote Procedure Calls (“RPC”), Discovery and Basic Configuration Protocol (“DCP”), as well as Transmission Control Protocol (“TCP”), and User Datagram Protocol (“UDP”).
It is common practice to isolate field devices from non-relevant Ethernet traffic, i.e., traffic not intended for the field device, by segmenting the network with properly configured Ethernet switches. Such a practice assumes only managed switches are used to provide segmentation and switch configuration capability. It also assumes networks use a star topology in order keep traffic from other devices to a minimum. For other topologies such as a line topology or a ring topology, the switch resident on the field device should be configured to pass only messages addressed to the field device to the device's application.
In other words, a field device switch should isolate the field device application from traffic destined for other network devices, such as another field device's real-time traffic, an HMI sending data to a printer, or a PLC sending data to the front office. However, there remain three classes of network traffic that a field device switch cannot isolate from its application. These are: network management and network application traffic; broadcast and multicast traffic; and erroneous or malicious traffic.
Network management and network application traffic is traffic to and from the device other than the time-critical data required by the core application of the device. This can include such things as connection establishment and maintenance messages to/from a PLC, Simple Network Management Protocol (“SNMP”) traffic for network maintenance, Link Layer Discovery Protocol (“LLDP”) messages for network topology management, FTP or HTTP traffic for other features of the device, etc. For example, if another device wants to access a field device's webserver or if a PLC requests network management information, there is no way for a switch to be configured to ignore these messages.
While a properly configured switch can isolate most undesired broadcast and multicast traffic from a device, all devices must receive and analyze some broadcast messages, primarily to support ARP requests, otherwise basic communication cannot take place. Therefore, it is common to limit the maximum number of broadcast packets that are allowed in a period of time or use other techniques to handle an overload of broadcast traffic. Whichever scheme is used, the field device still needs to process a reasonable percentage of this traffic in order to maintain basic communications.
Erroneous or malicious traffic is traffic directed to the field device, but for which there is no supported function or service in the device. For example, another element on the network can attempt to open a connection to a socket that is not supported by the device. The field device must still service this request, taking time away from the device's real-time communication. When this type of action happens repeatedly in an attempt to hack or crash the device, it can be considered malicious.
Since a switch cannot isolate a field device's application from the above classes of traffic, the problem is compounded when such traffic spikes to unexpected levels. It is not unusual for many devices on a network to send particular types of maintenance traffic at roughly the same time, for example. This simultaneous transmission results in a large number of packets to be managed in a relatively short time. In other cases, a network with a mix of field devices with different network management capabilities, i.e., Class A and Class B devices in the same PROFINET network, can result in packets going where they don't belong. On a PROFINET network, LLDP packets may be propagated from multiple devices causing a large spike in traffic for a network with many field devices.
In short, there is a lot more going on over an Ethernet network than on a serial fieldbus network. Segmentation and switches can only help so much, especially as factory networks evolve. Standard techniques for controlling traffic at the Ethernet switch level do not solve the problem of guaranteeing the real-time traffic and processing in the midst of this sort of traffic. This leaves field devices vulnerable to eventual performance problems or even failure over time as network traffic increases.
Despite the variability of network traffic, modern control systems are expected to continue to operate flawlessly
Accordingly, it is desirable to provide a method and an arrangement for field devices that inherently protect them from having to respond to all of these types of traffic.